Digital television apparatus for controlling a peripheral device via a digital bus

ABSTRACT

A minimal level of interoperability for exchanging audio/video (A/V) content and associated control between common consumer electronic (CE) devices is defined. This interoperability is based on the IEEE 1394 serial bus for the physical and link layers and makes use of AV/C or CAL as the control language. This invention provides for reducing the number of remote controls that the user might need by allowing remote control commands to always be received by a controlling device (e.g., digital television) and then routed to the appropriate peripheral device (e.g. digital VCR) after translation into a universal format.

This application claims the benifit of provisional applications.60/058,507 filed Sep. 11, 1997, Ser. No. 60/066,782 filed Nov. 25, 1997and Ser. No. 60/071,341 filed Jan. 14, 1998.

FIELD OF THE INVENTION

The invention involves a system for controlling multiple electronicdevices, such as consumer electronic devices or the like, viainterconnections such as digital data buses. More particularly, thisinvention concerns an arrangement for managing the interoperability ofsuch devices.

BACKGROUND OF THE INVENTION

A data bus can be utilized for interconnecting electronic devices suchas television receivers, display devices, video-cassette recorders(VCR), direct broadcast satellite (DBS) receivers, and home controldevices (e.g., a security system or a temperature control device).Communication using a data bus occurs in accordance with a bus protocol.Examples of bus protocols include the Consumer Electronics Bus (CEBus)and the IEEE 1394 High Performance Serial Bus.

A bus protocol typically provides for communicating both controlinformation and data. For example, CEBus control information iscommunicated on a “control channel” having a protocol defined inElectronics Industries Association (EIA) specification IS-60. On an IEEE1394 serial bus, control information is generally passed using theasynchronous services of the serial bus. Control information for aparticular application can be defined using for example, CommonApplication Language (CAL) or AV/C.

Today, most A/V devices are controlled with a remote control (RC) unit.The actual direct or physical link may be implemented with infrared(IR), ultrasound (US) or radio-frequency transmission (RF). The protocolbetween the peripheral device and the RC unit is device specific suchthat each device comes with its own RC unit. Each such peripheral deviceinterprets the key presses it receives via its direct link and carriesout the corresponding actions. Thus in the case of IR, control of aperipheral or target device is limited to a direct line-of-sight betweenthe RC unit and the peripheral device.

In today's analog audio/video (A/V) cluster, controlling peripheraldevices may include, but do not require, the activation of an On-ScreedDisplay (OSD) mechanism on a display device (i.e., TV). The OSD of suchAN devices is generated in the peripheral or target device (e.g.,digital VCR) and is output on the NTSC output of such devices the sameway as any other video signal. Thus, no additional hardware or softwareis needed in either the peripheral or the display device. FIG. 1illustrates a present A/V system 10 having a VCR 12 and a display device14 (e.g., television) that employs such a control methodology. Menusassociated with controlling VCR 12 are generated by the VCR 12 and areprovided to the display device 14 via the NTSC output of the VCR 12 as acomposite video. Unfortunately, to use the same approach (See FIG. 2)with a digital TV (DTV) as a display device 14′ is not practical sinceit would require the menus to be transported as MPEG-2 transportstreams. Generation of such streams necessitates integrating an MPEGencoder 15′ into all peripheral devices which greatly increases the costand complexity of such consumer electronic devices.

SUMMARY OF THE INVENTION

The present invention provides for a minimal level of interoperabilityfor exchanging audio/video (A/V) content and associated control betweencommon consumer electronic (CE) devices. The interface is based on IEEE1394 serial bus for the physical and link layers and makes use of acontrol language such as AV/C or CAL for managing OSDs and controllingthe connectivity of devices interconnected via a digital serial bus.Particularly, this invention provides for reducing the number of remotecontrols that the user might need by allowing remote control commands toalways be received by a controlling device (e.g., digital television orDTV) and then routed to the appropriate peripheral device aftertranslation into a universal format. A universal remote message iscarried across the serial bus and permits complex applications such asallowing the user to select a program to be recorded using the EPG ofthe DTV.

Although it will be possible to control each CE device through its ownfront panel or its own remote control, it is recognized that it ishighly desirable to control all devices on the cluster with one remotecontrol. One way to achieve this goal in a wav that furthersinteroperability is to use a standard control language (e.g., CAL orAV/C) to carry universal remote control messages across the bus. Thiswould also allow the control of devices which are not directly in theline-of-sight (e.g., devices in a different room or hidden, for examplebehind a cabinet door) as long as they are on the IEEE 1394 serial bus.Once the user has the peripheral device's menu displayed on a displaydevice, the display device can relay user initiated commands (i.e.,remote control (RC) keystrokes) intended for the peripheral device,received via any appropriate link (for example, IR link). The remotecontrol kevs would be mapped to a common command language, which allconsumer electronic devices from any manufacturer would be compliantwith, before they are transferred.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention may be better understood by referring to the encloseddrawing in which:

FIG. 1 shows, in simplified block-diagram form, the interoperabilitv ofa prior art audio/video system;

FIG. 2 shows, in simplified block-diagram form, the extension of theprior art interoperability between a digital VCR and a digitaltelevision;

FIG. 3 is a simplified schematic block diagram illustrating the IEEE1394 serial bus protocol;

FIG. 4 shows, in simplified pictorial diagram form, a cluster of digitalconsumer electronic devices outlining the path of user initiatedcommands;

FIG. 5 shows, in simplified schematic block-diagram form, theinteroperability of digital devices employing the present invention; and

In the drawing, reference numerals that are identical in differentfigures indicate features that are the same or similar.

DETAILED DESCRIPTION OF THE DRAWINGS

The use of IEEE 1394 serial bus has been suggested for many applicationswithin a Home Network environment. It is being discussed within VideoElectronics Standards Association (VESA) for use as a “whole homenetwork.” It is being built into the next generation PCs and will beused for many local peripherals including disc drives. Further, digitalaudio/video consumer electronic devices such as digital televisions(DTVs) and digital video cassette recorders (DVHS) may utilize a serialbus for interconnecting these devices.

IEEE-1394 is a high speed, low cost digital serial bus developed for useas a peripheral or back-plane bus. Some of the highlights of the businclude: dynamic node address assignments, data rates of 100, 200, and400 Mbits/sec, asynchronous and isochronous modes, fair bus arbitration,and consistency with ISO/IEC 13213. FIG. 3 illustrates the serial busprotocol for the IEEE 1394 serial bus 16 as a set of three stackedlayers.

The physical layer 18 consists of the physical signaling circuits andlogic that are responsible for power-up initialization, arbitration,bus-reset sensing, and data signaling. Two shielded low-voltagedifferential signal pairs, plus a power pair are defined for theIEEE-1394 serial cable. Signaling is done by using data-strobe bit levelencoding which doubles jitter tolerance.

Data is formatted into packets in the link layer 20. Two classes of datacommunication between devices are supported: asynchronous andisochronous. Asynchronous communication can be characterized as “allowsacknowledgment,” while isochronous communication can be characterized as“always on time.” The asynchronous service will be used primarily forcontrol and status messages while isochronous communication will be usedfor data streams such as MPEG video. The timely nature of isochronouscommunication is achieved by providing a cycle everv 125 μsec.Isochronous cycles take priority over asynchronous communication.

Asynchronous transfer can take place any time the bus is free. A minimumof 25 μsec out of every 125 μsec cycle is reserved for asynchronous datatransfer. Isochronous transfer provides a real-time data transfermechanism. An ongoing isochronous communication between one or moredevices is referred to as a channel. The channel has to be establishedfirst, then the requesting device is guaranteed to have the requestedamount of bus time every cycle.

The transaction layer 22 defines a complete request-reply protocol toperform bus transactions. Although transaction layer 22 does not add anyservices for isochronous data transfer, it does provide a path formanagement of the resources needed for isochronous services. This isdone through reads and writes to the control status registry (CSR).Transaction layer 22 also defines a retry mechanism to handle situationswhere resources are busy and unable to respond. Asynchronous data istransferred between IEEE-1394 nodes utilizing one of three transactions;“read-data” for retrieving data from a different node, “write-data” fortransferring data to a different node and “lock-data” for transferringdata to a different node for processing and then the data is returnedback to the original node.

Serial bus management 24 describes the protocols, services, andoperating procedures whereby one node is selected and may then exercisemanagement level control over the operation of the remaining nodes onthe bus. There are two management entities defined for IEEE-1394 serialbus; the isochronous resource manager 26 and the bus manager 28. Thesetwo entities mav reside on two different nodes or on the same node. Aseparate bus manager 28 may be absent from the bus. In thiscircumstance, the isochronous resource manager 26 exercises a subset ofthe management responsibilities normally assumed by the bus manager 28.The bus manager 28 provides a number of services including; maintenanceof the speed and topological map, and bus optimization. The isochronousresource manager 26 provides facilities for allocation of isochronousbandwidth, allocation of channel numbers, and the selection of the cyclemaster.

Node control is required at all nodes: node controller 30 implements theCSRs required by all serial bus nodes and communicates with the physical18, link 20, and transaction 22 layers and any application present inthe device. Node controller 30 component as well as CSR andconfiguration ROM facilities are used to configure and manage theactivities at an individual node.

For the IEEE 1394 serial bus to function properly, an isochronousresource manager (IRM) and a bus manager (BM) will be needed. Since mostclusters (i.e., devices interconnected via a digital bus) will include adisplay device of some kind, it should be required that a Set Top Boxwith Analog Display and DTV must be IRM and BM capable. In some cases,such as an all audio cluster, a display device may not be present. Inthis case, it should also be required that a Digital Audio Amp be IRMand BM capable.

IRM 26 provides the resources necessary for the serial bus tocooperatively allocate and de-allocate the isochronous resources,(channels and bandwidth), required for orderly isochronous operations.IRM 26 provides a common location for the other nodes. to check onavailability of channels and bandwidth, and to register their newallocations. IRM 26, whose location is known immediately upon completionof the self identify, process, also provides a common location whereserial bus nodes may determine the identity of BM 28, if one is present.

BM 28, if present, provides management services to other nodes on theserial bus. These include activation of a cycle master, performanceoptimization, power management, speed management and topologymanagement.

Functional Control Protocol (FCP) is designed in order to controldevices connected through an IEEE-1394 bus. FCP uses the IEEE-1394asynchronous write packet for sending commands and responses. TheIEEE-1394 asynchronous packet structure with FCP embedded in the datafield shown below. The Command/Transaction SET (CTS) specifies thecommand set (e.g. AV/C, CAL). It also allows a vendor unique set to beencapsulated in the packet.

FCP Frame in the payload of an asynchronous write Destination ID TI Rt0001 Pri Source ID Destination offset Data Length Extended tcode HeaderCRC CTS Zero pad bytes (if necessary) Data CRC

FCP frames are classified as command frames, and response frames. Thecommand frame is written into a command register on a peripheral and theresponse frame is written into a response register on a controllingdevice. The standard specifies two addresses for the command and theresponse.

The structure of the isochronous packet in IEC-61883 is shown below. Thepacket header is composed of two quadlets of an IEEE-1394 isochronouspacket. (A quadlet is four 8-bit bytes.) The Common Isochronous Packet(CIP) header is placed at the beginning of the data field of anIEEE-1394 isochronous packet, immediately followed by the real timedata.

Data Length Tag Channel Tcode Sy Header CRC CIP Header Real Time DataData CRC

Data length is the data field length in bytes, Tag indicates whether CIPexist (01) or not (00), Channel specifies the isochronous channelnumber, Tcode=1010, and Sy is an application specific control field.

The 61883 standard defined a generic format for consumer A/Vtransmission. This format has a two quadlet header as shown below. Inthe table, SID is Source node_ID, DBS is data block size in quadlets,Fraction Number (FN) allow you to divide source packets for bus timeutilization, Quadlet Padding Count (QPC) indicates number of quadletscount, Source Packet Header (SPH) is a flag to indicate whether thepacket has a source packet header, rsv indicates reserved for future,Data Block Counter (DBC) is a continuity counter, FMT indicates theformat ID such as MPEG2, DVCR, and Format Dependent field (FDF) isformat ID specific.

0 0 SID DBS FN QPC SPH rsv DBC 1 0 FMT FDF Reserved time stamp

The concept of plugs and plug control registers is used to start andstop isochronous data flows on the bus and to control their attributes.Plug control registers are special purpose CSR registers. The set ofprocedures that use the plug control registers to control an isochronousdata flow are called Connection Management Procedures (CMP).

Isochronous data flows from one transmitting device to zero or morereceiving devices by sending the data on one isochronous channel on theIEEE-1394 bus. Each isochronous data flow is transmitted to anisochronous channel through one output plug on the transmitting deviceand is received from the isochronous channel through one input plug oneach of the receiving devices.

The transmission of an isochronous data flow through an output plug iscontrolled by one output Plug Control Register (oPCR) and one outputMaster Plug Register (oMPR) located on the transmitting device. oMPRcontrols all common isochronous data flow attributes while oPCR controlsall other attributes. Similar registers (iPCR, and iMPR) exist for thereception of isochronous data. There is only one oMPR (iMPR) for alloutput plugs (input plugs). The contents of oMPR (iMPR) includes; datarate capability and number of plugs among others. oMPR (iMPR) contains aconnection counter, channel number, and data rate among others.

There are a number of management procedures for each connection typethat allows an application to establish a connection, overlaying aconnection, and breaking a connection. These procedures involveallocation of IEEE-1394 resources, setting appropriate values into theplug control registers, reporting possible failure conditions to theapplication, and managing connections after a bus reset. One such CMPfollows.

To transport isochronous data between two A/V devices on a IEEE 1394serial bus, it is necessary to connect an output plug on thetransmitting device to an input plug on the receiving device using oneisochronous channel. The relationship between one input plug, one outputplug and one isochronous channel is called a point-to-point connection.Similarly there are broadcast-out connections (one output plug and oneisochronous channel) and broadcast-in connections (one input plug andone isochronous channel).

The flow of isochronous data is controlled by one output plug controlregister (oPCR) and one output master plug register (oMPR) located onthe transmitting side. oMPR controls all the attributes (e.g. data ratecapability, broadcast channel base etc.) that are common to allisochronous flows transmitted by the corresponding A/V device.

The reception of an isochronous data flow through an input plug iscontrolled by one input plug control register (iPCR) and one inputmaster plug register (iMPR) located in the receiving device. iMPRcontrols all the attributes (e.g. data rate capability etc.) that arecommon to all isochronous data flows received by the correspondingdevice.

The major steps involved in establishing a connection are allocation ofIEEE 1394 resources (e.g. bandwidth) and setting channel, data-rate,overhead-ID and connection counter in oPCR and iPCR.

An isochronous data flow can be controlled by any device connected tothe IEEE 1394 serial bus by modifying the corresponding plug controlregisters. Although Plug control registers can be modified byasynchronous transactions on IEEE 1394 serial bus, the preferred methodof connection management is through the use of AV/C. It is fully withinthe scope of this invention to employ CAL for connection management.

Application Control Languages

In order for a consumer electronic device to interact with other devicesinterconnected via a IEEE 1394 serial bus, a common product mode andcommon set of commands must be defined. Three standard approaches fordevice modeling and control are CAL, AV/C and the approach adopted forthe Universal Serial Bus (USB).

CAL and AV/C are control languages that distinguish between logical andphysical entities. For example, a television (i.e., a physical entity)may have a number of functional components (i.e., logical entities) suchas a tuner, audio amplifier, etc. Such control languages provide twomain functions: Resource allocation and Control. Resource allocation isconcerned with requesting, using and releasing Generic Networkresources. Messages and control are transported by the FCP as defined inIEC-61883 and discussed above. For example, CAL has adopted an objectbase methodology for its command syntax. An object contains and has soleaccess to a set number of internal values known as instance variables(IV). Each object keeps an internal list of methods. A method is anaction that an object takes as a result of receiving a message. When amethod is invoked, one or more IVs are usually updated. A messageconsists of a method identifier followed by zero or more parameters.When an object receives a method, it looks through its list of methodsfor one which matches the method identified in the message. If found,the method will be executed. The parameters supplied with the messagedetermine the exact execution of the method.

The design of control languages is based on the assumption that allconsumer electronic products have a hierarchical structure of commonparts or functions. For example, CAL treats each product as a collectionof one or more of these common parts called Contexts. These contexts aredesigned to allow access to product functionality in a uniform way. Thecontext data structure is a software model defined in each device thatmodels the operation of all device functions.

A context consists of one or more objects grouped together to form aspecific functional sub-unit of a device. Like an object, context is amodel of a functional sub-unit. Devices are defined by one or morecontexts. CAL has defined a large set of contexts to model various typesof consumer electronic devices. Each context, regardless of what productit is in, operates the same way.

Objects are defined by a set of IVs, for example the IVs for a binaryswitch object contain required and optional IVs. Required IVs include avariable (current_position) that indicates whether the switch is on oroff and the default position (default_position) of the switch. OptionalIVs include function_of_positions; reporting_conditions; dest_address;previous_value and report_header. IVs are just like variables in anysoftware program and are supported in CAL as Boolean, Numeric,Character, and Data (array). The IVs in an object can be categorizedinto three general groups: support IVs, reporting IVs, and active IVs.The support IVs are usually read only variables that define theinstallation use of the object and operation of the active IVs. ActiveIVs of an object are the variables that are primarily set or read tooperate the object.

The interaction between a controlling device (e.g., DTV) and peripheraldevice (e.g. DVHS) can mainly be divided into two major categories:

i) A machine-machine interaction where both controlling device andperipheral are machines. It is important to note that for this type ofinteraction, there is no user initiation at the time of the actualinteraction. However, it is possible that the user preprogrammed thecontrolling device to carry a specific action at a specific point intime.

ii) A user-machine interaction where a human is initiating actions onthe controlling device.

The primary means of user-machine input for analog audio/video devices(A/V) today is the use of a remote control (RC) unit or the front panel.Some of the interaction may also make use of an on-screen display (OSD)mechanism. In this kind of interaction, the user interacts directly withthe peripheral. In the case of today's remote controls, the messagingprotocol used is device and/or manufacturer specific. The peripheraldevice processes the received commands and carries out the requiredactions. If an OSD is used, this includes keeping track of the RC keysprocessed and updating the displayed OSD accordingly after eachkeypress. Currently there is no standard messaging protocol. This leadsto the use of multiple remote control units (i.e., different RC unitsfor the TV, VCR, etc.). The available universal remote controllers onthe market have limited capability. These devices typically change theirmessage format depending on which “device focus” button has beenpressed.

The present invention gives the users the capability to interact withthe A/V devices interconnected via a IEEE 1394 serial bus in a manner towhich they are accustomed (i.e. use of an RC unit possibly in connectionwith an OSD). That is, a base level of interoperability between devicesfrom different manufacturers at a minimal cost is established. Defininga standard messaging mechanism to allow for the transport of RC keypresses to other units via the IEEE 1394 serial bus allows for the useof the RC unit associated with the controlling device (e.g., DTV) as atruly universal RC unit.

In operation, the user will choose, via the DTV, a video source (i.e.,peripheral) device such as a DVCR. Once the peripheral device is chosen,the DTV sets up a connection to receive a digital A/V program (typicallyover an isochronous channel) and an OSD (typically over the asynchronouslink). The user may then “focus” the remote control (RC) unit on theDVCR by pressing the VCR button. Now, for subsequent RC button pushes,the DTV will receive the RC key presses since the DTV understands theformat of the RC modulation and data format. The DTV knows that the RCkeypress is intended for the DVCR and not the DTV. The DTV will thentranslate the RC key press to a predetermined standardized universal keycode and transport it across the serial bus to the DVCR. The DVCR willreceive the standardized universal key code and will then perform thedesired action.

For example, in the situation of an RCA DTV 14″ and a Sony DVCR 12″, asillustrated in FIG. 4, a RC command from an RCA remote controller 13″ isreceived over the IR link and thus will be in the RCA format. The RCADTV 14″ will translate that to the universal format and transfer itacross the serial bus 16″. The Sony DVCR 12″ will receive the universalcommand and perhaps translate it into the Sony format and then takeaction. The translation of the commands can be thought of as translatingfrom one language to another. As example of a RC key press would be“PLAY”. This command is commonly available on many RC units, even thoughthe format of the message is different from manufacturer tomanufacturer.

Defined below are various methods to transfer an on-screen display menufrom a peripheral device to a controlling device, for example a digitaltelevision.

To simplify the transfer of OSD information a “Pull” method to transferthe OSD information from the peripheral device to the controlling devicemay be used. With this method, the bulk of the OSD data is transferredfrom the peripheral to a display capable device by asynchronous readrequests issued by the display capable device. That is, the controllingdevice reads the OSD information from the memory of the peripheral bymaking use of at least one block read transaction of IEEE 1394. Thecontrolling device is informed of the location and size of the OSD datavia a “trigger” command which is sent from the peripheral to the displaydevice when the peripheral is ready to begin transferring data.

Since the OSD information on the peripheral device is updated inresponse to RC keypresses, the controlling device (or DTV) is alerted ofthe availability of newly updated data. This can be achieved by sendinga short message (i.e., “trigger”) to the OSD object of the controllingdevice. It should be noted that such a message needs to inform thedisplay device of the starting location as well as length of the OSDdata to be read. The length is necessary since the application in thecontrolling device is going to make use of asynchronous readtransactions of IEEE 1394.

If the length is greater than what would fit into the maximum packetlength possible for the particular IEEE 1394 network the controllingdevice may initiate multiple block read transactions until all the OSDinformation has been read. In addition to the starting location andlength of the current OSD data to be transferred to a display device, afield indicating the type of OSD data is useful. This is especiallyuseful since in this case the same mechanism can also be used to triggerthe OSD mechanism of a display device to display such things as error,warning and/or status messages. The differentiation of the type of OSDdata is helpful for the display device and/or user to decide whether itreally wants it to be displayed (for example a user watching a movie maywant to ignore things such as status messages).

An asynchronous push method primarily uses IEEE 1394 serial busasynchronous write transactions initiated by the peripheral device towrite the OSD data onto the controlling device. This approach allows aperipheral device to write its menu contents into a controlling device.Since it is expected that the menus will be larger than the MTU (MaximumTransfer Unit) of the bus, a fragmentation header can be added. The menutransport layer should add this header. On the receiving side, thislayer reassembles the menu and passes it to higher layers.

An isochronous transport method provides for “broadcasting” the OSD dataover one of the isochronous channels provided by IEEE 1394 serial bus.Bandwidth would need to be reserved and held as long as the peripheraldevice is being controlled using the OSD.

An asynchronous stream method uses an asynchronous stream to carry theOSD information. An asynchronous stream is essentially the same as anisochronous stream except that there is no bandwidth reservation and thestream is sent in the asynchronous portion of the bus cycle.

Navigation through the menu of the peripheral device is achieved byrelaying all RC key presses over the IEEE 1394 serial bus in the form ofuniversal commands to the peripheral device. This method of navigationis compatible with any method of OSD representation. Only minimalsoftware is needed on both the peripheral and controlling devices. Thecontrolling device only needs to have a well defined wav of sending keypress information to the peripheral. Similarly the peripheral deviceonly needs to be able to update the OSD information in a well definedmanner. The OSD data does not need to contain any information toidentify function and/or parameters. The peripheral device simply keepstrack of incoming input in the form of keypresses and updates its OSD asit sees fit.

In an A/V cluster interconnected by an IEEE 1394 serial bus, it ispossible to relay RC keypresses to the peripheral via the bus ratherthan through a direct link (e.g. IR) as illustrated in FIG. 5. This ispossible by defining a standard message format which providesinformation about the RC key press to the peripheral device. With such asystem 10″, (1) one can relay RC commands from a remote controller 13″to devices which are not in direct line-of-sight (i.e. in another roometc.), and (2) the RC unit 13″ associated with the controlling device(e.g., DTV) 14″ can effectively act as a universal RC, (for example,even though the RCA brand remote controller for the RCA TV may notdirectly operate with the Sony VCR, the RCA TV can relay the RCkeypresses via standardized messages over the IEEE 1394 serial bus tothe VCR). Standard messages can be defined such that they can also relayfull character sets in multiple languages according to the unicodestandard (a subset of ISO 10646 as defined by the Unicode Consortium)besides being able to relay all possible special function keys found ona RC unit. This allows for relaying keypresses on an IR keyboard as wellas RC.

Relaying remote control (RC) unit keypresses to the peripheral device ismore completely defined below. However, such a method is extendible todevices such as computer keyboards, control panels, etc.

Control of a peripheral device (e.g., DVCR 12″) may start by selectingthat device as the source on the DTV 14″. In this context, sourceselection refers to the controlling device acquiring all necessaryparameters such that subsequent RC keypresses are relayed to theintended peripheral. Such parameters include the peripheral device'snode_id, EUI, etc. and can be obtained from the registry table. Thesource selection operation can be initiated by the user clicking on anicon on a graphical user interface (GUI) of the controlling device or aRC key such as VCR1 on a RC unit. Source selection tags outgoing RCmessages (such as, “channel up” and “channel down”) as applying to theDVCR 12″.

Once a peripheral device has been selected, all subsequent RC keypressesintended for the peripheral device are relayed to that peripheral'sUniversal Keyboard Input object. A typical format of the packet sent isshown below. The packet is sent to the peripheral device by making useof the asynchronous block write transaction of the IEEE 1394 SERIAL BUSbus.

Universal IR Remote Message Encapsulation <-----1 byte------><------1byte------><------1 byte------><------1 byte-----> FCP CTS = 10h ADPU =E8h Univ. Context = Object ID = ??h 00h Method ID = 46h IV ID = 66hDelimiter = F5 Delimiter = F5 Argument End of Command = F9h ←←←←←←←←←←←←1 Quadlet →→→→→→→→→→→→

The variable 24 bit keypress_info is defined as follows:

Universal IR Remote Message Format Code_type (8 bits) Code_value (16bits)

The variable code_type defines the semantics of the next 16 bitscontained in the code_value.

Universal IR Remote Message Fields Code_type Semantics of Code_value00₁₆ RC key_code as defined through standardization 01₁₆ Unicode otherreserved for future expansion

The peripheral device receiving the RC key press information by itsUniversal Keyboard Input (UKI) software module carries out thecorresponding action. Not all actions necessarily require the use of anOSD. An example is the PLAY command which is relayed to DVCR 12″. It issufficient that the playing action is initiated, no feedback to the userin the form of an OSD is required.

On the other hand, some control functions may take place through an OSDdisplay mechanism. For such devices, after receiving the key pressinformation through its UKI object, the OSD information is updated ifnecessary and the controlling device is sent a short message indicatingthe availability of updated OSD information (in the case of theAsynchronous Pull Method). Thus, the application on the controllingdevice can read the OSD information from the peripheral and display it.

It is important to note that an idle (not being controlled by anyone atthat moment) peripheral device receiving a RC command through theindirect link needs a mechanism to avoid taking an action twice when itreceives the same message via multiple paths. This can happen when theperipheral device is manufactured by the same company as the controllingdevice. In such a situation, it is possible that the peripheral devicemay receive the RC command as a universal RC message over the serial busand may also receive the message via the direct IR link. Anotherpossibility may be if a user is controlling a peripheral device over theserial bus from a remote location and another person is attempting tocontrol the same peripheral device via a direct IR link using theassociated remote controller. One way to do multipath resolution is forthe peripheral to activate a timer upon reception of the RC commandsthrough the indirect link. This timer is reset each time a new RCcommand is received through the indirect link. Any RC keypressesreceived over the direct link are ignored during the period this timeris active. The timer by definition becomes inactive after a period ofinactivity and the device returns to its idle state where it responds tokeypresses relayed either through the direct or the indirect link. Inaddition, once control is initiated through the indirect link by aparticular node, the peripheral shall ignore any additional RC keypressmessages coming from other nodes.

Further, it may be desirable to prevent general access to a device. Insuch a case, a special relationship called “locking” develops, foreither a short or long duration of time, between two devices. Lockingallows a device to control the access to some or all parts of the lockeddevice. The controlling device is the “locking device” and the object ofthe locking relationship is the “locked device.” The lockingrelationship allows a device to bind itself to another device.

There are various levels of locking desired. In many instances, anapplication requires only a device level locking. However, there arecases when it is desirable to lock at an object level. Once suchsituation is a VCR application where it could be desirable to lock thetransport mechanism while allowing other devices to edit or add timerevents. Likewise, although it is desirable to lock the display object ina TV to guarantee proper display, it is not desirable to lock thedevice's ability to respond to other communications.

The following locking scheme allows a device, context, or object to betreated as a network resource. The resource can be directly obtained oracquired from other devices residing on the network. There are twolocking approaches discussed.

A request to lock the device is made directly, and the device mustdetermine if it can accommodate the lock or if a previous lock takesprecedence. If there is an impediment to making a new lock, a lockbroker requests that previous impeding locks are dissolved. Once theprevious locks are dissolved, the broker grants the locking request. Thelocked device must insure that all impeding locks are dissolved beforeit allows the new lock.

The second type of locking is resource locking. In resource locking, thelocking device broadcasts a request that all devices dissolve locks thatwould prevent the new lock from occurring. Once sufficient time haspassed to insure all previous conflicts are resolved, the device setsthe lock.

During operation through the direct link, a peripheral device simplyreceives inputs from its RC unit or front panel and carries outcorresponding actions. However, there is a slight complication when, asa result of these actions, an OSD is supposed to be generated on adisplay device. Since in this case, the actions of the peripheral wereinitiated through its own direct link, the peripheral has no knowledgeas to which node on the network to display its OSD. Therefore a devicewhich detects initiation of control through its direct link, can sendmessages to each OSD capable device. It is up to the display device todecide whether to act on this message or not. For example, if focus onthat display device has been given to VCR1 and it receives an messagefrom VCR1, it is quite natural for the display device to act on it. Ifthe display device is not focused on the particular device, the user canbe alerted of the presence of an OSD display request by a remote unitbut can choose to ignore it depending on the data type in the receivedmessage. Since the actual control is through the direct link, it hasabsolutely no effect on the peripheral whether any or multiple displaydevices choose to display the OSD. On the other hand, this mechanism mayalso be used to inform the user of error conditions, warnings etc. whichthe user may or may not want to have displayed at the time. Therefore,the message includes a field for data type to indicate whether the OSDdata presented to the display device is a warning message, errormessage, normal OSD data etc.

Similarly, a timer mechanism can be implemented for the direct link suchthat during the time it is active, any RC keypress information receivedthrough the indirect link is ignored.

All devices that are capable of using remote control commands mustimplement the Universal Keyboard Input software module. On theperipheral device, the receiver for the RC key press is implemented by,for example, a CAL object called “Universal Keyboard Input”. This is avery simple object such that the CAL command sent to it is extremelysimple, short and easy to parse. This simplicity is important since thislevel of interoperability should not require a full implementationcontrol application language. The exact syntax which makes up theFunctional Control Protocol (FCP) frame as defined ay IEC 61883 is shown(below). The syntax of the entire packet is consistent with the generalframework/syntax of CAL. However, at this level of interoperabilitv adevice relaying RC keypresses can simply put together the packet belowrather than implementing the full CAL mechanism.

A sample of some Universal Remote Key codes are defined below; furthercodes may be defined as needed.

RC key RC key_code 0 0000₁₆ 1 0001₁₆ 2 0002₁₆ 3 0003₁₆ 4 0004₁₆ 5 0005₁₆6 0006₁₆ 7 0007₁₆ 8 0008₁₆ 9 0009₁₆ Power 000A₁₆ VCR1 000B₁₆ VCR2 000C₁₆DSS 000D₁₆ Cable 000E₁₆ Audio1 000F₁₆ Audio2 0010₁₆ TV1 0011₁₆ TV20012₁₆ Rewind 0013₁₆ Fast Forward 0014₁₆ Play Forward 0015₁₆ PlayForward Fast 0016₁₆ Play Forward Slow 0017₁₆ Play Backward 0018₁₆ PlayBackward Fast 0019₁₆ Play Backward Slow 001A₁₆ Record 001B₁₆ Pause001C₁₆ Stop 001D₁₆ Mute 001E₁₆ Up Arrow 001F₁₆ Down Arrow 0020₁₆ LeftArrow 0021₁₆ Right Arrow 0022₁₆ Reset 0023₁₆ Menu 0024₁₆ Sleep 0025₁₆Channel Up 0026₁₆ Channel Down 0027₁₆ Volume Up 0028₁₆ Volume Down0029₁₆ Antenna 003A₁₆ Enter 003B₁₆

Discover Process

The discovery process allows the controlling device to discover otherdevices in the network. This process is activated by a bus reset andserves to search and discover existing devices on the network. A busreset may be caused by connecting/disconnecting a device, softwareinitiated reset etc. This software module relies on some informationstored on each device configuration ROM. This information is referred toas Self Description Device Table (SDDT) and contains information such asModel #, Location of menu, URL, EUI Vendor ID etc.

The SDDT of the controlling or display device contains a pointer to aninformation block which contains information about the displaycapabilities of the device. The information block may include type ofdisplay (interlaced or progressive), maximum bytes per line, resolutionmodes supported (full, ½, ⅓), mix weights supported, maximum bits/pixelsupported for palette mode (2, 4, 8) and maximum block size supportedother methods of discovery can also be used to obtain this informationsuch as, the Home Plug and Play defined for CAL or the subunitdescriptors defined for AV/C.

After the bus initialization is complete, the discovery manager of thecontrolling device reads the SDDT located in the ROM of each connecteddevice. This information is built into a registry table. Each device onthe IEEE 1394 serial bus will have a registry table which will be usedto keep track of other devices on the bus and their capabilities. Forall devices on the bus, this registry table (or registry) will beupdated during the discovery process. The registry provides services tothe application for mapping volatile characteristics(e.g., 1394 node_ID,IP address etc.) a non-volatile 64-bit EUI (Extended Unique Identifier)for identifying any node on 1394 bus.

The registry table is maintained by the registry manager within eachdevice and contains the information for each node to provide the servicepreviously specified. This registry table is constantly updated by thediscovery manager on bus resets. An example of the construction of sucha registry Table follows:

64-bit 1394 IP Manufac/ Device EUI node_ID address Model # Type

The fields of the registry table are defined as:

64-bit EUI is a 64-bit number that uniquely identifies a node among allthe Serial Bus nodes manufactured world-wide.

node_vendor_id chip_id_hi chip_id_lo ←←←←←←←←←←← 1 quadlet = 32 bits→→→→→→→→→→→

1394 node_ID is a 16-bit number that uniquely identifies a Serial busnode within a IEEE 1394 SERIAL BUS subnet. The most significant 10 bitsare the bus ID and the least significant bits are the physical ID. BusID uniquely identifies a particular bus within a group of bridged buses.Physical ID is dynamically assigned during the self-identificationprocess.

IP address is a 32-bit private IP address assigned dynamically.

Manufacturer/Model # is obtained from the device's SDDT and is used toinform the customer of possibilities for selecting a source.

Device Type is also obtained from the device's SDDT and is used toinform the customer of possibilities for selecting a source. This fieldmay also be useful in determining what stream format should be used. Forexample, a game machine may not use MPEG 2 as an output format.

The registry can be used to determine the IEEE 1394 serial bus addressfor any node on the home network based on the 64-bit EUI of that node.Correlation to a stable identifier such as the EUI is important sincenode addresses can change during a bus reset.

On each of the CE devices, some setup occurs at installation time(through the use of the Device Setup Manager) as described above formapping other devices on the cluster to output or input channels of thatdevices. This does not necessarily mean that IEEE 1394 isochronouschannels are allocated at this time. Another possibility is that eachdevice merely loads a selection menu with devices found on the networkby looking at the SDDT. Interaction can start by first addressing thedisplay device (assumed to be digital in this example) and selecting thedevice that the user desires to control (e.g., digital VCR). When thishappens, an isochronous channel is set up between the DVHS and thedisplay device.

Many remote controls have special functions which only have meaning forthe peripheral device. These special functions may not be integrated onthe RC associated with the controlling (e.g., DTV) device. Thus thefunction of these kevs can be made available on a menu from theperipheral.

Further, the present invention permits the control of non-video devicesby using a graphical user interface. As stated earlier, the displaydevice (i.e., DTV) would be a good choice for a controlling device sinceit will almost always be present on the cluster. A non-video devicewould provide menus in the same way as video devices (described above).However, the device would need to store its own menus.

In some cases, it is better to have coordinated control of severaldevices at once. For example, this may be useful in the case of dubbing.This coordination is difficult to do using only commands which map to anIR remote control. Additionally, it will be desirable to have thecapability to control some CE devices from a PC. This is where a fullcontrol language with device models such as CAL or AV/C could be useful.

While the invention has been described in detail with respect tonumerous embodiments thereof, it will be apparent that upon a readingand understanding of the foregoing, numerous alterations to thedescribed embodiment will occur to those skilled in the art and it isintended to include such alterations within the scope of the appendedclaims.

What is claimed:
 1. A digital television apparatus comprising: (a) meansfor communicating via a digital bus with a peripheral device; (b) meansfor receiving, from a data entry means associated with said digitaltelevision apparatus, a user initiated command associated withcontrolling said peripheral device, said user initiated command beingrecognized by said digital television apparatus and comprising headerinformation and control information for controlling an operating mode ofsaid peripheral device; (c) means for mapping said control informationinto a universal command capable of being interpreted by said peripheraldevice, said peripheral device not being responsive to said userinitiated command; and (d) means for transferring said mapped controlinformation over said digital bus to said peripheral device.
 2. Thedigital television apparatus of claim 1 further comprising: (a) meansfor receiving, from said peripheral device, menu data associated with anon-screen display of said peripheral device; and (b) means, coupled tosaid receiving means, for displaying said menu data.
 3. The digitaltelevision apparatus of claim 2 and further comprising: means forupdating a portion of said on-screen display in response to said menudata.
 4. The digital television apparatus of claim 2 wherein said menudata defines user selectable functions associated with said peripheraldevice.
 5. The digital television apparatus of claim 4 wherein saidperipheral device is a non-video device.
 6. The digital televisionapparatus of claim 1, wherein said mapping means appends code type datato said universal command, said code type data indicating to saidperipheral device that a received code is in a universal command format.7. A method for controlling a peripheral electronic deviceinterconnected via a IEEE 1394 serial bus to a digital televisionapparatus, said method comprising: (a) determining, in response to a busreset, said peripheral electronic device interconnected via said serialbus; (b) communicating via said serial bus with said peripheralelectronic device; (c) receiving, from a data entry means associatedwith said digital television apparatus, a user initiated commandassociated with controlling said peripheral electronic device, saidcommand having a format recognized by said digital television apparatusand comprising control information for controlling an operating mode ofsaid peripheral electronic device; (d) mapping said control informationinto a universal command format capable of being interpreted by saidperipheral electronic device, said peripheral electronic device notbeing responsive to said command; and (e) transferring said mappedcontrol information over said serial bus to said peripheral electronicdevice.
 8. The method of claim 6, wherein the mapping step furthercomprises appending code type data to said mapped control information,said code type data indicating to said peripheral electronic device thata received code is in said universal command format.
 9. A method forcontrolling a peripheral consumer electronic device interconnected viaan IEEE 1394 serial bus to a digital television comprises: (a)receiving, via said serial bus, a control signal from said digitaltelevision, said control signal being translated from a format onlyrecognized by said digital television; and (b) initiating a timer togenerate a time period in response to said control signal received viasaid serial bus, said peripheral device only responding to additionalcommands received via said serial bus during said time period.
 10. Themethod of claim 9 wherein said peripheral device is selected from a menuassociated with said digital television, said menu listing the availableperipheral devices.
 11. The method of claim 8 wherein said peripheraldevice receives said control signal via a direct link, said peripheraldevice performs the step of: (a) sending a message to said digitaltelevision, said message indicating the availability of digital dataassociated with an on-screen display of said peripheral device; (b)receiving an acknowledgment from said controlling device; and (c)transporting said digital data over said serial bus to said digitaltelevision.
 12. The method of claim 11 wherein said step of initiating atimer comprises: initiating a timer to generate a time period inresponse to said control signal received via said direct link, saidperipheral device only responding to additional commands received viasaid direct link during said time period.